|
SCOOP (Simple Concurrent Object Oriented Programming) is a concurrency model designed for the Eiffel programming language, conceived by Eiffel's creator and designer, Bertrand Meyer. SCOOP defines a way for an object oriented program to be written without the concept of threads, locks, or other typical multiprogramming methods. This allows the compiler or runtime environment to optimize the amount of concurrency as well as eliminate typical design flaws such as deadlock. The model was first designed in the early 1990s and published in 1993 in the Communications of the ACM〔Bertrand Meyer: ''Systematic Concurrent Object-Oriented Programming'', in Communications of the ACM, 36, 9, September 1993, pp. 56-80, also available (online ).〕 An updated version was described in chapter 30 of the book ''Object-Oriented Software Construction''.〔Bertrand Meyer: Object-Oriented Software Construction, 2nd edition, Prentice Hall, 1997〕 A prototype implementation was developed in 1995 by Eiffel Software. An article by Compton and Walker〔 〕 provides an overview of SCOOP and describes another early implementation. Nienaltowski, Arslan and Meyer have published a description of the model as of 2003.〔 P. Nienaltowski, V. Arslan and B. Meyer: ''Concurrent object-oriented programming on .NET'', in IEE Proceedings on Software, vol. 150, no. 5, October 2003, pages 308-314, also available (online )〕 Work on SCOOP proceeded at the Chair of Software Engineering at ETH Zurich.〔ETH Zurich, Chair of Software Engineering: (SCOOP project page )〕 SCOOP became available as a standard part of EiffelStudio early in 2011.〔Eiffel Software: (SCOOP: Concurrency for Eiffel )〕 ==Technical overview== SCOOP works by allowing references to certain objects to be declared as separate. In the code below, an entity local_inventory is declared as a separate type, by specifying the Eiffel language keyword separate in the declaration.local_inventory: separate INVENTORY A separate object may be handled by a SCOOP processor that is different from the processor handling the referencing object. A SCOOP processor is the abstract notion of an autonomous thread of control that handles the execution of operations on one or more objects. SCOOP processors are independent of underlying concurrency mechanisms like processor threads, multiple processor cores, and distributed computer systems. In addition to the concept of separateness, SCOOP exploits the principles of Design by Contract as part of the SCOOP strategy for synchronizing access to shared separate resources. For example, a precondition for a consumer wishing to access an item in the inventory example above, might be that such an item does currently exist. This would be expressed with a contract on the feature of class INVENTORY which returns the item. item: PRODUCT -- Current item require inventory_has_item: has_item In traditional, sequential processing, a client intending to call local_inventory.item would be responsible for making certain that the precondition local_inventory.has_item holds before making the call. If the call to item were made in a state in which has_item did not hold, the caller would incur a precondition violation exception. In the presence of SCOOP and given the separateness of local_inventory, making the check on has_item before calling item would not be reliable. This is because the state of local_inventory could have been changed by requests from other SCOOP processors between the time that the check was made and the time that item could be called. As a result, when SCOOP is enabled, the precondition has_item is transformed from a correctness condition, which will cause an exception in the case of a violation, to a wait condition. The wait condition will cause the execution of item to be delayed until such time as has_item holds. In the Eiffel Software implementation, if SCOOP is not enabled, the separate keyword is ignored and sequential processing is assumed.抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「SCOOP (software)」の詳細全文を読む スポンサード リンク
|